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Preface 


Your first business process management (BPM) projects, although radically different in the 
tooling and the methodology for those people who are directly involved in the project, will be 
chartered, funded, measured, and managed as with any other IT project. However, for an 
enterprise to accelerate the radical value that a BPM project proves, the enterprise must 
transform. Change must occur around projects. Funding, staffing, governance, infrastructure, 
and virtually every aspect of how BPM solutions are implemented, must change before the 
enterprise can mature to meet those strategic goals that accelerate the value of BPM beyond 
a handful of projects. 

This change is the BPM transformation. Unlike the challenges of the first few BPM projects, 
this transformation represents an unprecedented challenge to those enterprises that are 
midway through the pursuit of BPM excellence. 

This IBM® Redpaper™ publication seeks to eliminate the uncertainty that organizations 
face in this next generation of BPM, maturing beyond the success of BPM projects. The goals 
and concepts of dozens of mature BPM organizations are consolidated here and categorized 
to provide you with clear mandates, with hope that this clarity will provide purpose, and that 
this purpose will drive excellence. The audience for this IBM Redpaper includes Executive 
Sponsors, Team Leaders, Lead Architects, Infrastructure Owners, and in general, anyone 
interested in transforming the enterprise around BPM principles to create a Center of 
Excellence (CoE). 
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1 


Introduction 


There are no easy answers, but there are simple answers. We must have the courage to do 
what we know is ... right. 

This adage (from President Reagan) is a reminder that as nascent BPM programs around the 
world have matured over the last decade, so have the challenges that are encountered and 
goals sought. Your enterprise no longer needs to prove the value of BPM, but needs to 
accelerate it. The challenges in doing so are complex and numerous, as are the teams that 
are chartered to address them. These teams are defined by the new generation of challenges 
they seek to surmount, the risks they hope to abate, and the promises they hope to fulfill. 

Consider Figure 1-1 . Might this diagram reflect reality within your enterprise? 
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Business Process Manager 
Practitioner Resources 



"Do we all have the same job?" 
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Business Process Manager 
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Figure 1-1 BPM team roles 
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As mentioned previously, your first BPM projects, although radically different in the tooling 
and the methodology for those directly involved in the project, will be chartered, funded, 
measured, and managed as with any other IT project. The challenges of an initial BPM 
project are the same kind as traditional IT development. Analysts still participate. Although 
they might engage the line of business and document processes differently, these radical 
differences are not visible at higher levels in the enterprise. 

Applications are still developed, tested, and deployed. Although these applications are 
re-envisioned in a “process” context and prioritized from a perspective on business value, this 
radical change is experienced only by those directly involved with your first BPM projects. 
Senior management might be aware that something is radically different in these BPM 
projects, but this level of the organization is unchanged. Under the penumbra of “project,” 
there are many differences, but from an elevated point of view, most aspects appear the same 
as before BPM. 

For an enterprise to accelerate the radical value that a BPM project proves, the enterprise 
must transform. Change must occur around projects. Funding, staffing, governance, 
infrastructure, and virtually every aspect of how BPM solutions are implemented must change 
before the enterprise can mature to meet those strategic goals that accelerate the value of 
BPM beyond a handful of projects. This change is the BPM transformation. Unlike the 
challenges of the first few BPM Projects, this transformation represents an unprecedented 
challenge to those enterprises that are midway through the pursuit of BPM excellence. 

This Redpaper seeks to eliminate the uncertainty that organizations face in this next 
generation of BPM: maturing beyond the success of BPM projects. The goals and concepts of 
dozens of mature BPM organizations are consolidated here and categorized to provide you 
with clear mandates, with hope that this clarity will provide purpose, and that this purpose will 
drive excellence. The intended audience for this Redpaper includes Executive Sponsors, 
Team Leaders, Lead Architects, Infrastructure Owners and Process Excellence leads that are 
an implied part of your BPM Center of Excellence as it takes shape. 


1.1 The need for a BPM governance organization 

Transforming your enterprise requires time and patience, investment in people and 
technology, and commitment from executive leadership, middle management, and the 

workforce. 

Although most BPM projects begin as individual, loosely connected (or entirely disconnected) 
efforts, today’s operational landscape demands scalability and enterprise-wide adoption, 
which eventually necessitates bringing individual BPM projects together in a consolidated 
BPM program. 

To meet the demand of scalability and enterprise-wide adoption of BPM, a BPM Center of 
Excellence (CoE) must address the following key focus areas of responsibility: 

► Defining a higher business goal or vision, driving BPM initiatives and aligning individual 
projects with that vision 

► Executing a scalable delivery resource model for discovering, implementing, deploying, 
managing, and supporting BPM initiatives 

► Administering a shared infrastructure for hosting and maintaining the solutions that are 
the outcomes of BPM initiatives 
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Through experience with both successful and challenged BPM program initiatives, we 

learned that the following aspects are true: 

► A BPM initiative can survive only by achieving business value; and business value must 
support the strategic objectives of the organization. Business value must be measured 
objectively with supporting data and be easily visible and communicated to leadership. 
Without demonstrating business value, the BPM journey will end, or stagnate at best. 

► The transformative nature of BPM requires a shared infrastructure (a BPM system, or 
BPMS) that scales with a growing demand for BPM projects. This shared infrastructure 
must support the collaborative aspects and governing demands of BPM as a discipline. 

► The purpose of a BPM initiative is to create a repeatable delivery model for improving 
business performance. Long-term success depends entirely on establishing a scalable 
BPM delivery model as a discipline. Focusing on organizational enablement in BPM 
methods is essential for an uninterrupted BPM journey. Without BPM method enablement, 
even the best BPMS will achieve no value. 


1.2 The pillars of a BPM governance organization 

Throughout this IBM Redpaper, we use the following terms to represent the three key focus 
areas and the responsibilities in each that must be fulfilled to completely address BPM 
governance. Although it is possible for a single governing group of people to have all three of 
these responsibilities, a more likely approach is that certain individuals within the group will 
carry one or more of these responsibilities by committee. Each responsibility is unique in its 
charter and requires individuals with appropriate levels of authority, skills, and experience to 
carry out its charter. 

► Strategy 

This key focus area is responsible for defining business goals and setting the course for 
BPM initiatives across a broad area; likely, the entire business enterprise. The scope of 
responsibility includes strategy and long-term planning for the overall BPM initiative, BPM 
advocacy within the organization, a funding model for the BPM program, and tracking key 
performance indicators (KPIs) along an enterprise-wide value chain to measure the 
success of the overall BPM initiative beyond the tactical success of individual projects. 

► Delivery 

This key focus area is responsible for creating a scalable delivery model for staffing and 
delivering BPM initiatives. This responsibility includes sourcing, enabling, staffing, and 
retaining BPM talent. It also includes creating, maintaining, and governing tactical best 
practices for the entire BPM project lifecycle. 

► Shared infrastructure 

This key focus area is responsible for designing, building, and governing a shared 
infrastructure (a business process management system, or BPMS) that is used for 
hosting, executing, and maintaining the process applications that are the outcomes of 
BPM initiatives. This responsibility includes hardware configuration, software installation, 
administration, upgrades, deployment, and maintenance. 
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1 .3 Scope of this paper 


The three key focus areas (strategy, delivery, and shared infrastructure) have related but 
distinctly separate mandates. Each is supported by individuals who possess the correct range 
of authority, skills, and experience. In this IBM Redpaper, we outline a broad framework of 
areas of responsibility, activities, recommended organizational structure, and skills required to 
succeed with the governing responsibilities in each of these key focus areas. 

This framework is not meant to be a detailed blueprint for building your own central BPM 
governing organization. But it should inform those efforts. It is also not meant to be a panacea 
to ailing individual projects. A framework for succeeding with individual projects is covered in 
Scaling BPM Adoption: From Project to Program with IBM Business Process Manager, 
SG24-7973: 

http://www.redbooks. i bm.com/abstracts/sg247973.html 
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Strategy 


This chapter describes the key focus area of strategy in a BPM Center of Excellence. This 
chapter contains the following topics: 

► 2.1 , “Purpose of strategy in a BPM CoE” on page 6 

► 2.2, “Areas of responsibility for strategy in a BPM CoE” on page 6 

► 2.3, “Organization of strategy in a BPM CoE” on page 6 

► 2.4, “Areas of responsibility in depth” on page 7 

► 2.5, “Organization in depth” on page 23 
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2.1 Purpose of strategy in a BPM CoE 

In a 2012 Gartner CIO survey 1 , CIOs across industries named the following top 12 priorities: 

► Increasing enterprise growth 

► Attracting and retaining customers 

► Reducing enterprise costs 

► Creating new products or services 

► Delivering operational results 

► Improving efficiency 

► Improving profitability 

► Attracting and retaining the workforce 

► Improving marketing and sales effectiveness 

► Expanding into new markets 

► Improving governance, compliance, risk 

► Implementing finance and management controls 

Four of the top six priorities are process-related, process-driven, or processes themselves. 

Given this increasing importance of process management and governance for chief business 
executives, it is now more important than ever for any BPM-related initiative to have a 
governing body that sets goals, seeks visibility, and drives change at a level that is directed 
specifically at executive leadership of the organization. This importance, in summary, is the 
purpose of the BPM Center of Strategy. 


2.2 Areas of responsibility for strategy in a BPM CoE 

Broadly, the domains of concern that fall under strategy can be organized as follows: 

► Vision, goals, strategy, and KPIs for the overall BPM Initiative 

► Organizational awareness, education, and advocacy 

► Funding model for individual BPM initiatives 

► Funding for governing body including both resource allocation and enablement 

► Inventory of processes along the enterprise value chain 2 

In addition to instituting definitions of each of these domains, the strategy element of a BPM 
CoE must engage in activities that advance and implement them. For an in-depth view of 
these domains, see 2.4, “Areas of responsibility in depth” on page 7. 


2.3 Organization of strategy in a BPM CoE 

After these areas are specifically identified and given concrete articulation, giving shape to 
the actual organization that will advance the areas of responsibility becomes important. This 
organization can be envisioned in the following typical areas: 

► Roles 

► Skills 

► Organizational Structure 

For an in-depth view of these areas, see 2.5, “Organization in depth” on page 23. 

1 http://www.gartner.com/technology/cio-priorities/2012-cio-agenda.jsp 

2 Enterprise value chain is an industry standard framework for analyzing and connecting the key business value 
pillars of an organization and tracing tactical activities back to these high-level pillars. 
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2.4 Areas of responsibility in depth 

A BPM CoE must articulate and drive an enterprise-level strategy (from a business and a 
technology perspective) for all BPM initiatives across the entire organization. 

This mandate can generally be divided into the following categories: 

► “Vision, goals, strategy, and KPIs for the overall BPM initiative” 

► “Organizational awareness, education, and advocacy” on page 10 

► “Funding model for BPM initiatives” on page 1 1 

► “Inventory of processes along the enterprise value chain” on page 15 

2.4.1 Vision, goals, strategy, and KPIs for the overall BPM initiative 

Creating a vision of a desired outcome from the BPM initiative is one of the first 
responsibilities of the strategy element of a BPM CoE. This vision should articulate the 
current state that gave rise to the need for BPM within the organization, the high-level 
challenges that must be overcome by using the BPM initiative, and what the shape of the 
organization will look like after these challenges are overcome. 


Sample vision statements for enterprise BPM initiatives: 

► Reduce the “time to decision” for our customer so that we can take a larger market 
share from our chief competitor. 

► Increase visibility of KPIs to allow the company to be more agile in the marketplace by 
focusing our activities. 

► Reduce cost of sales by shorting all related administrative processes. 

► Increase customer satisfaction by reducing the amount of rework done in any customer 
contact processes. 


The goals for the BPM initiative should be measurable and clearly in support of the vision. We 
suggest following the SMART paradigm, which is the industry standard framework for 
creating goals. SMART has the following meaning: 

► Specific 

► Measurable 

► Attainable 

► Realistic 

► Timely 

See the Goal Setting Guide website for more information: 

http://www.goal -setting-guide.com/goal -setting-tutorial s/smart-goal -setting 

Taken together, the vision and the goals should complement each other in creating a standing 
business case for BPM throughout the organization. 


Sample goals to support your vision statement: 

► Reduce cost that is related to process-rework by 75% across the value chain. 

► Institute standard process visibility metrics for every operational process. 

► Reduce time to return customer contact by 50%. 
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An important note is that the vision and goals stated here are not limited to the BPM CoE 
itself, but rather to the entire BPM initiative, which can include all other organizations related 
to governing, operationally executing, or benefiting from BPM. 

These goals must be a good mixture of end-states beyond which the problem can be 
considered solved, and a set of in perpetuity goals that should continue to carry and support 
your journey toward full BPM maturity. 

After the first draft of the vision and goals are in place, the strategic element of the BPM CoE 
is responsible for creating high-level guidelines, key strategic decisions, and a sequence of 
significant planned events. The sequence should form a timeline that supports the 
achievement of the goals, and thus, the vision. The guidelines, decisions, and the event 
timeline can serve as a planning and strategy guide that informs the overall BPM initiative at 
various stages of maturity, in areas of technology and also business strategy. 


Sample strategy assets that can support your goals: 

► A representation of the Enterprise Value Chain (EVC) for your organization. 

► Technology guidelines, such as the following examples: 

- We will use an enterprise service bus for all integrations necessary for any BPM 
solutions. 

- The BPM platform must not be the business data system of record for any BPM 
solutions. 

- BPM technology should be used only to implement business solutions where there 
is a clear fit-for-purpose (as defined by the Center of Strategy). 

► Business solution guidelines, such as the following examples: 

- All BPM solutions should provide KPI reports that demonstrate the assumed return 
on investment (ROI) for implementing the solution. 

- All BPM solutions should provide an increasing level of change control directly to the 
business audience, without sacrificing risk mitigation and auditability. 

► Key technology decisions, such as the following examples: 

- We use IBM FileNet® for any content management-related aspect to a BPM 
solution. 

- We use IBM Operational Decision Manager for any advanced rules-related aspect to 
a BPM solution. 

- We need to “sunset” the heritage workflow platform. 

► Key business decisions, such as the following examples: 

- Streamlining business processes related to customer service carry a higher priority 
than all other business processes. 

- Phase 1 of any partner-related business process needs to be optimized for these 
top three partners first and the remainder can be addressed in Phase 2. 

► Key technology events timeline 

► Key business events timeline 


Depending on the ambition of the vision, the effort required to achieve the goals, and the 
aggressiveness of the timeline, you can elaborate or abbreviate the level of detail required of 
the strategy to suit the situation. 
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Key performance indicators 

A crucial point to understand is that the creation of the vision, goals, and strategy will not by 
itself achieve any benefit for the organization. What is required to realize tangible benefit is to 
also own the driving of your ideas to tactical depth, by being actively involved in individual 
BPM projects, and by using the projects as vehicles to advance your strategy. The immediate 
results of those projects will create benefits that might initially seem unrelated to the 
enterprise goals and strategy, but are in fact leading indicators of improvement that directly 
affect the mandate of the BPM CoE. These leading indicators are commonly called key 
performance indicators (KPIs). 

KPIs must be predetermined by the strategy element of the BPM CoE, as the framework 
within which evidence of strategic progress is gathered. 


Sample KPIs with which to evaluate the success of your strategy: 

► BPM releases per year 

► Development cost per process step 

► Per-process ROI or time to break even 

► The reuse dividend, which is time or money that is saved because of reusable assets 
Reuse alone without including cost is misleading. 

► Post-assessment health check score of projects 

► The number of integration methods, systems of record, legacy BPM, and decision 
management systems retired 

► The percent of business investment per release (how much work was done outside 
of IT) 


Supporting activities 

Activities can be initial and perpetual. 


Sample supporting activities for defining, monitoring, and driving vision, strategy, 

goals, and KPIs: 

The initial activities are as follows: 

► Defining an enterprise value chain 

► Defining a specific vision, set of goals, and timeline for goals 

► Defining key technology and business guidelines for the entire initiative 

A perpetual activity might be a regular meeting to accomplish the following tasks: 

► Address key technology and business decisions that impact the BPM initiative and fall 
under the initial guidelines 

► Examine the results of established KPIs to determine if the overall BPM initiative is 
moving in the correct direction 

► Maintaining and adjusting the initial vision, goals, strategy, timeline, and guidelines to 
keep up with on-the-ground realities 
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2.4.2 Organizational awareness, education, and advocacy 

An important aspect of a BPM CoE is to cultivate and elevate cultural awareness of BPM 
throughout the enterprise. Simply stated, cultural awareness means leading the charge for 
using BPM in areas of the organization that have not already embraced BPM. 

This responsibility is perhaps the most important for the strategy element of the BPM CoE, 
second only to the “vision, goals, and strategy” mandate. The primary mission of the CoE, 
which is to shepherd enterprise-level BPM initiatives, cannot be accomplished without 
expanding the BPM footprint beyond its initial introduction to the business. This expansion is 
much more likely to be successful if it stems from a desire and confidence to use BPM to 
solve a real business problem, rather than by corporate mandate. 

Increasing awareness, education, and general appetite for BPM should be reflected directly 
within the vision, goals, strategy, and KPIs that are defined by the Center of Strategy. This 
area is also where developing a plan or compiling artifacts does not address the gap by itself. 
The Center of Strategy must proactively and regularly engage key decision makers in the 
larger organization outside the BPM ecosystem with the express goal of greater BPM 
adoption. Adoption can be measured by KPIs that seek to measure the number of areas in 
the enterprise value chain that are using BPM as a prime driver. 


Sample KPIs that measure successful BPM cultural adoption: 

► Distinct contributors to process discovery (participating IBM Blueworks Live™ 
accounts) 

► Playback attendance (greater weight given to sponsors, process owners, SMEs, end 
users) 

► Number of playbacks (formal and informal) per project per unit of time 

► Number of releases (updates to production) per project per unit of time 

► Inventory completion percent (how many processes against the enterprise value chain 
have been identified and documented in Blueworks Live) 

► Inventory categorization percent complete (of the identified processes, how many have 
been categorized against the inventory guidelines) 

For more information, see “Inventory guidelines” on page 15. 


Supporting activities 

Supporting activities might include reviews, education, and outsourcing tasks. 


Sample supporting activities for driving cultural advocacy, education, and 
awareness of BPM: 

► Business valuation reviews for projects, measuring KPIs are alignment with enterprise 
value chain 

► Regular open-attendance BPM education forums 

► Crowdsourcing a process inventory and refining it with experts later 
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2.4.3 Funding model for BPM initiatives 

The funding model concept for BPM initiatives exists at two levels: 

► This more direct level is the funding model for the BPM CoE itself including the different 
elements of strategy, delivery, shared infrastructure. 

► This level is a common funding model for individual BPM projects that are governed by the 
BPM CoE. 

When planning for a BPM initiative, you must account for the time and cost that are 
associated with talent acquisition, knowledge sharing, skills development, not just resource 
“head” count and infrastructure assets. 

Funding model for governance organizations 

The simplest possible solution to funding a governance organization is to have it funded 
directly out of the office of the CIO. This solution has the advantage of bringing a clarity of 
mission, focus, and expected results to the organization. 

As the organization grows and the volume of projects that require governance increases, it 
will become necessary to have the fixed costs be funded by the CIO’s office and the variable 
and volume-related costs driven by a internal-cross-billing model that charges the individual 
business units for their projects (or shared portion of) directly. 

The hybrid model for drawing a portion of the funding directly from individual projects can be 
a recognition of the benefits that are gained by the individual projects through the use of 
resources from the governing organizations. Resources might include common reusable 
assets (technical and business), guidance, reviews, best practices, and shared infrastructure. 
In effect, this can be viewed as a BPM tax in exchange for participating in the BPM 
ecosystem. 
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Figure 2-1 describes this model. 



Funding model for individual projects 

Initially, most BPM projects are funded directly by the business area that needs a BPM 
solution, and are consumed by a specific IT organization that serves that business area. Your 
first project (maybe two) might entirely fund the initial delivery and infrastructure for BPM. (For 
this reason, first projects must adhere closely to corporate strategy with large and visible 
business value.) 

However, as the BPM organization matures and achieves enterprise-wide adoption, it is 
beneficial to combine this point-to-point funding model with a common funding model that is 
used to gain access to an enterprise-wide BPM ecosystem. The goal of such access is to 
drive consistency in terms of how the ROI for each individual project is framed within the 
context of strategic BPM goals. This concept is the same maturity concept in the way that we 
see no individual business unit paying for all of the hardware and software infrastructure that 
is required to read and send email throughout the enterprise; although early adopters of email 
might have carried the entire burden of the original investment. 

Over time, as this shared ecosystem develops and demonstrates the ability to successfully 
and repeatedly deliver individual BPM projects (the element of delivery in your BPM CoE), 
the need for a point-to-point funding model diminishes and a single, consolidated funding 
model emerges. 

This centralized model will grow beyond providing oversight and delivery and evolve into a 
funding office where projects without existing funding can propose a business case and apply 
for funding. 
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The actual implementation of funding models can vary significantly from one organization 
to another depending on their larger financial model. Looking beyond the specific 
implementation, the primary aim of a central funding model is to drive consistency and 
alignment, and the secondary aim is to provide a source (or brokerage) of funding for BPM 
initiatives that seek funding. 

Figure 2-2 and Figure 2-3 on page 14 show how this funding model evolves. 
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Supporting activities 

Develop a framework, price, and timeline. 


Sample supporting activities for creating, driving and maintaining a BPM initiative 
funding model: 

► Developing and executing a framework for chartering a BPM project 

► Developing and presenting a price-case for a variety of funding models along with a 
timeline in which each model becomes viable 
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2.4.4 Inventory of processes along the enterprise value chain 

This section describes the following information: 

► The value of doing a process inventory 

► Framework for doing process inventory and analysis 

► Analysis guidelines 

► Supporting activities 

The value of doing a process inventory 

The initial use of BPM to address business problems with process-oriented solutions is 
typically of primary value in the immediate business areas. Some early projects might also be 
valuable for the operational experience with BPM and a BPMS. 

However, after an enterprise value chain is defined as part of the vision, goal, and strategy 
mandate, an important step is to identify key supporting processes that drive the enterprise 
value chain. These key processes exist within a context and framework that immediately has 
enterprise-wide strategic importance and should not require you to build a new business case 
when it comes time for implementation. 

The exercise of discovery, identification, and documentation is commonly known as an 
inventory. The goal is to identify a pipeline of special processes that inherently have 
enterprise-level value and directly affect the vision, goals, and strategy that are defined by the 
strategy element of the BPM CoE. These processes should be treated differently from other 
processes that are not directly related to the enterprise value chain. 

What differentiates these key processes from other processes is their implied higher ROI, 
which justifies accelerating the funding to implement them. Also, addressing key processes 
through BPM can affect the KPIs that are used to measure the success of BPM in a much 
more direct way than other processes that are not related directly to the enterprise value 
chain. 

The greater mandate of overseeing and aligning all BPM projects within the enterprise is 
what sustains the initiative, the real goal of the BPM CoE is to complete the inventory and 
process improvement implementation of key processes on the enterprise value chain. 

Framework for doing process inventory and analysis 

A process inventory exercise spanning the entire value chain usually yields a large number of 
processes and can potentially take a long time, depending on the depth of analysis and time 
that are devoted to each process. 

To effectively manage the time and effort required to complete a process inventory we provide 
a few basic guidelines and best practices that should allow the strategy element of your BPM 
CoE to produce actionable results in a bounded effort. 

Inventory guidelines 

The inventory framework is based on the following basic guidelines: 

► Distribute the process inventory data-gathering activities 

Although the process inventory should be centralized, there is no reason to centralize the 
data-gathering activities. Be sure the business units (divisions, departments, teams) 
catalog their processes (see Table 2-6 on page 22) and submit to the BPM CoE for further 
analysis and prioritization. 

► Various process improvement tactics can exist, which vary in degree of effort and 
automation. 
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An individual process from the inventory is likely to benefit the most from only one of the 
tactics at any level of maturity. 

► Not all processes in the inventory can benefit from a full BPM automation project. 

Identifying and documenting these processes is still valuable because they will likely 
benefit from one of the process improvement tactics (outlined in this section). Therefore, it 
is also valuable to go through a categorization exercise that attempts to align each 
process identified in the inventory against the appropriate process improvement tactic 
from which it can benefit the most (as determined by the Process Inventory Analysis 
Framework). 

► Processes categorized along the Process Improvement Tactics matrix will likely be 
weighed more heavily toward standard operating procedure (SOP) optimization than 
toward full BPM automation 

Few processes warrant the high cost of fine-grain automation against the expected ROI. 
However, an important point to note is that we have an entire spectrum of process 
improvement tactics to choose from, and that a full automation project is not the only 
option. 

Table 2-1 describes the process guidelines. 


Table 2- 1 Inventory process guidelines 


Process improvement tactic 

Explanation 

Typical symptoms 

Leave Alone 

No incentive to improve. ROI 
from process improvement 
effort is too low. 

Ad-hoc processes happen 
infrequently or are processes 
already and will not benefit from 
further improvements. 

Standard Operating Procedure 
(SOP) Optimization 

Significant room for 
improvement by analyzing and 
optimizing the SOP without 
BPM automation. 

Processes are performed with a 
script (over the phone or in 
person). 

Blueworks Live (BWL) 
Automation 

Significant room for 
improvement by the automation 
capability in Blueworks Live 
without BPM automation. 

Processes are conducted today 
in email or recurring meetings. 

Business Process Manager 
(BPM) Swivel-Chair Automation 
for Consistency 

Significant value from 
consistency improvement by a 
orchestration and automation 
within BPM. All individual 
activity-level-automation is kept 
at the check-list level {Swivel 
over to X system and do Y. 
Swivel back and click Finished 
when done with this checklist). 
This step might also be called 
coarse grained automation. 

Primary opportunity for value is 
increased consistency 
(everyone does the same thing 
the same way) in the process. 
Processes often exhibit 
symptoms of rework. 

Processes can also benefit 
from enhanced visibility using 
BPM reporting and analysis 
tools, with the intent of gaining 
operational efficiency (workload 
balancing, and threshold 
fine-tuning). 
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Process improvement tactic 


Explanation 


Typical symptoms 


BPM Swivel-Chair Automation 
for Visibility 


BPM Hybrid Automation 


BPM Full Automation 


Not enough is known about this 
process to place it in one of the 
other “Process Improvement 
Measure” categories. A 
swivel-chair approach 
(described in the previous row) 
is called for, but primarily for the 
purpose of increasing visibility 
and diagnostics about the 
process. 

The intent here is a short period 
of swivel-chair automation, with 
predesigned, targeted reports 
that yield a fresh categorization 
in this matrix after the pilot 
period. 

Significant room for 
improvement in both 
consistency and some (but not 
all) individual activity 
automation. This process is 
orchestrated through BPM and 
some individual activities are 
also automated with a direct 
integration to the back-end 
system where the work is 
supposed to be done. Some 
other activities may remain in 
the swivel-chair realm as 
defined above as. 

In this hybrid mixture of 
swivel-chair and automated 
activities, the automated 
activities have a high expected 
ROI and the swivel-chair 
activities do not. 

Individual activity automation 
can also be called finegrained 
automation . 

Significant room for 
improvement in both 
consistency and all individual 
activity automation. This 
process is orchestrated through 
BPM and all individual activities 
are also automated with a direct 
integration to the back-end 
system where the work is 
supposed to be done. 

All individual activities have a 
high expected ROI. 


Processes where the primary 
opportunity is unclear and more 
visibility or analysis is needed. 
Processes can benefit from 
further analysis with BPM tools 
(custom reports, optimizer, and 
so on) and a recategorization in 
the matrix following the 
analysis. 


Processes where there is a 
clear benefit from automation, 
visibility and control, across the 
board at a Coarse Grain level, 
and in a limited fashion at the 
Fine Grain level. 

However, this benefit comes at 
a high integration effort cost. 
Some of the integrations 
involved with individual 
activities in these processes 
are non-value-added and thus 
should be done through the 
Swivel-Chair approach. 


These processes have a clear 
benefit from automation, 
visibility and control, both at a 
coarse-grain and at a fine-grain 
level, throughout. 

The cost of integrations is 
manageable and 
commensurate with the benefit 
that is gained by process 
improvement. 
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Figure 2-4 shows the inventory process. 



Analysis guidelines 

Beware of analysis paralysis when you process inventory. Triage first, then prescribe a 
solution. 

When doing analysis on a large number of business processes, trying to do an end-to-end 
analysis for each process, one by one, is not advisable. You should balance the time and 
effort with the benefit to be effective. In this section, we provide several guidelines for bulk 
analysis and how to do two levels of business analysis in Blueworks Live. 

Level 1 analysis 

Level 1 analysis should focus on looking at symptoms and leading indicators of opportunities 
for improvement. Level 1 analysis seeks to categorize each process in the inventory within the 
Process Improvement Tactics matrix. The categorization paves the way for Level 2 analysis. 

The Process Improvement Tactics matrix represents the high-level generic recommendation 
that the process is likely to benefit from. The matrix also implies the type of Level 2 analysis 
that should be performed to obtain specific recommendations for each category. 
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As a part of doing Level 1 analysis, we suggest that the following attributes be recorded (as 
detail fields if using Blueworks Live) for each process model in the inventory: 

► Process level attributes (Table 2-2) 


Table 2-2 Process level attributes 


Process attribute 

Description 

Volume 

On average, the number of instances of this process that are 
started per year 

Total Cost 

On average, the activity cost of each instance of the business 
(hard cost, opportunity cost, rework cost, risk exposure costed 
average) 

Total Benefit 

On average, the dollar value of the benefit per instance to the 
business; for example, revenue, customer satisfaction, brand 
loyalty 

% Rework in the process 

Amount of time that some or all of the process needs to be 
redone to have an acceptable outcome. 

Potential Automation Benefit 

Whether this process benefits from automation. The analyst can 
quickly provide an instinctive answer to this question without 
extensive calculation or statistical analysis. Answers include 

high, medium, low, or none. 

Confidence in Analysis 

The confidence level of the analyst that the values provided for 
the fields reflect reality. Questions to ask are: Were you talking 
to the correct people? Are they biased? Did you spend sufficient 
time validating? Are you extrapolating too much? Answers 
include high, medium, low, or none. 


► Activity level attributes (Table 2-3) 


Table 2-3 Activity level attributes 


Activity attribute 

Description 

Volume 

On average, the number of instances of this process that are 
started per year 

Total Cost 

On average, the activity cost of each instance of the business 
(hard cost, opportunity cost, rework cost, risk exposure costed 
average) 

Total Benefit 

On average, the dollar value of the benefit per instance of this 
activity to the business; for example, revenue, customer 
satisfaction, brand loyalty 

Integration Effort 

To automate this activity, whether a significant effort is needed 
to build an integration to a system outside the BPM platform. 
Answers include high, medium, low, or none. 

Value Added 

Whether this activity is beneficial in any material way to the 
process itself or other dependent processes. Answers include 

high, medium, low, or none. 

Potential Automation Benefit 

Whether this activity can benefit from automation. The analyst 
can quickly provide an instinctive answer to this question without 
extensive number crunching or statistical analysis. Answers 
include high, medium, low, or none. 
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Level 1 analysis can be done by categorizing permutations of the values of four basic fields 
(Volume, Cost, Benefit, Automation Effort) from the above set of activities, against the 
Process Improvement Tactics matrix. 

If you captured these fields in your Blueworks Live space, export your space to a tool such as 
Microsoft Excel to generate the type of analysis shown in the following section. 

Typical Level 1 analysis mapping 

Table 2-4 describes Level 1 analysis mapping. 


Table 2-4 Level 1 analysis mapping 


Process symptoms and attributes 

Applicable process improvement tactic 

Volume: Low 
Cost: Low 
Benefit: Low 
Automation Effort: High 

Leave Alone 

Volume: Low 
Cost: Medium 
Benefit: Medium 
Automation Effort: High 

SOP Optimization 

Volume: Medium 
Cost: Medium 
Benefit: Medium 
Automation Effort: High 

Blueworks Live Automation 

Volume: High 
Cost: Medium 
Benefit: High 

Automation Effort: Medium or High 

BPM Swivel-Chair Automation for Consistency 

Volume: ? (implies unknown) 

Cost: ? 

Benefit: ? 

Automation Effort: Medium or High 

BPM Swivel-Chair Automation for Visibility 

Volume: Medium or High 
Cost: Medium or High 
Benefit: Medium or High 

Automation Effort: Medium 

Hybrid BPM Automation 

Volume: High 
Cost: High 
Benefit: High 

Automation Effort: Medium or Low 

Full BPM Automation 


Level 2 analysis 

A good way to think of the levels is as follows: 

► Level 1 analysis is as an initial diagnostic and triage tool for processes. 

► Level 2 analysis is the subsequent prescriptive solution that can alleviate the foremost 
detrimental symptoms in the process. 

Level 2 Analysis should focus on building a business case and specific process improvement 
recommendations. 
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Table 2-5 describes the Level 2 analysis types for each diagnostic category. 


Table 2-5 Level 2 analysis mapping 


Applicable process 
improvement tactic 

Level 2 analysis 

Leave Alone 

Rationale for why this process should be left alone. An “anti” business 
case. 

SOP Optimization 

► A set of recommendations for modifying standard operating 
procedures without introducing any automation 

► A new to-be process for documentation in Blueworks Live 

Blueworks Live Automation 

► A new to-be process built as an automated process application in 
Blueworks Live 

► The use of standard Blueworks Live reports for automated 
process applications 

BPM Swivel-Chair 
Automation for Consistency 

► A new to-be process built for documentation in Blueworks Live. 

► A new to-be process built for swivel-chair implementation in BPM. 

► A business case for the effort involved in implementing the above, 
outlining the quantifiable consistency benefits to the business unit 
funding the initiative. 

► An analysis plan that eventually leads to a reclassification of this 
process within this matrix 

BPM Swivel-Chair 
Automation for Visibility 

► A new to-be process built for documentation in Blueworks Live 

► A new to-be process built for swivel-chair implementation in BPM 

► A business case for the effort involved in implementing 
swivel-chair, outlining the quantifiable visibility benefits to the 
business unit funding the initiative 

► A limited pilot release plan for the swivel-chair implementation, to 
minimize the impact of dual work inherent in swivel chair 

► An analysis plan, which eventually leads to a re-classification of 
this process within this matrix 

Hybrid BPM Automation 

► A new to-be process built for documentation in Blueworks Live 

► A new to-be process built for Implementation in BPM, with some 
integration to back-end systems 

► A business case for the effort involved in implementing the 
swivel-chair, outlining the quantifiable benefits to the business unit 
funding the initiative. 

► A limited pilot release plan, if necessary, for the swivel-chair 
implementation, to minimize the impact of system stability and 
potential swivel-chair work in Release 1 . 

Full BPM Automation 

► A new to-be process built for documentation in Blueworks Live 

► A new to-be process built for Implementation in BPM, with 
integration to all necessary back-end systems 

► A business case for the effort involved in implementing the 
swivel-chair, outlining the quantifiable benefits to the business unit 
funding the initiative 

► A limited pilot release plan, if necessary, for the swivel-chair 
implementation, to minimize the impact of system stability in 
Release 1 


Chapter 2. Strategy 21 





















Supporting activities 

Use the following iterative approach when executing a coordinated effort to inventory, 
document, prioritize, and analyze hundreds of processes (or more) by using the analysis 
techniques that are outlined in the preceding section. 

1 . Identify and catalog all processes listed in Table 2-6. No modeling or diagramming is 
required at this level. This initial cataloging of business process can be managed centrally 
and collaboratively (with a tool such as Blueworks Live), but primarily is done by process 
owners from their respective business units. 

Table 2-6 Inventory processes for analysis 


Process 

Examples 

ID 

1 , 50, FZ64A 

Current format 

Visio, PDF, Word, PowerPoint 

Process name 

Negotiate contract 

Status 

Current, Out of Date, Tribal Knowledge 

Process owner 

Owner’s name 

Original author 

Author’s name 


2. Complete milestone level modeling in Blueworks Live for all processes and add another 
column named Process improvement tactic to Table 2-6, as listed in Table 2-7. This step 
too can be performed by process owners from their respective business units but 
governed by the BPM CoE for further discovery, analysis, and data collection. 

Table 2-7 Inventory processes for analysis 


Process 

Examples 

ID 

1 , 50, FZ64A 

Current format 

Visio, PDF, Word, PowerPoint 

Process name 

Negotiate contract 

Status 

Current, Out of Date, Tribal Knowledge 

Process owner 

Owner’s name 

Original author 

Author’s name 

Process improvement tactic 

SOP, optimization, Blueworks Live Automation 


3. Standardize all processes in Improvement Tactic categories that are related to BPM 
Automation or Swivel Chair. The process of standardization should involve modeling these 
processes down to the task level (but not to the action level). 

4. Perform Level 2 analysis on all processes that are identified in step 3. (Steps 4 and 5 can 
be done in parallel.) 

5. Standardize all processes in Improvement Tactic categories other than BPM Automation 
or Swivel Chair. (Steps 4 and 5 can be done in parallel.) 
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2.5 Organization in depth 


The strategy element of a BPM CoE requires specific skills, envisioned in roles that are then 
organized in a decision, making and executing structure against their areas of responsibility. 


2.5.1 Roles 


A useful way to think of the roles that are involved in creating the strategy element of a BPM 
CoE is as follows: 

1 . Start with a core group. 

2. Later, expand into an extended set of roles, likely specific to your organization, and that 
support this core group. 

Core roles 

This section defines the core roles that support the strategy element of a BPM CoE. 

Executive Sponsor 

This role is the highest level executive who is sponsoring the entire BPM initiative (most likely, 
in the form of direct funding of the business case) in the organization that requires the BPM 
CoE. 

► Provides senior sponsorship 

► Leads direction-setting for the BPM CoE 

► Establishes and evolves a funding model 

► Governs the escalation processes 

Business Architect 

This role is typically a senior business and process engineering analyst who understand the 
entire value chain and was directly involved in creating the business case for the enterprise 
BPM initiative. 

► Establishes and documents the enterprise value chain 

► Initiates and governs the enterprise process inventory and analysis exercise 

► Develops and prioritizes enterprise process road map 

► Establishes and governs analysis standards 

► Establishes and governs measurement standards 

BPM Technical Architect 

This role is the highest level of technical leadership involved in selecting and owning the BPM 
infrastructure (BPMS) in the organization. This person makes key strategic decisions 
involving, using, acquiring, and phasing out technology in the BPM software stack. 

► Plans and evolves system capacity and architecture requirements 

► Establishes an enterprise architecture stack involving the BPM system 

► Creates, standardizes, and governs “best fit for purpose” guidelines for the BPM system 

► Promotes and governs process and rule component reuse 

► Articulates system performance and capacity management expectations to the shared 
infrastructure group 
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BPM Strategy Lead 

This role is typically someone in a full-time project or program management role for the entire 
Center of Strategy. This lead acts to organize, articulate, and drive the agenda set by the 
other core members. This role is key because the other members likely do not have a full-time 
commitment to the BPM CoE strategic mission. 

► Manages the strategic elements of the BPM CoE 

► Prioritizes overall project pipeline 

► Plans and prioritizes overall talent development requirements 

► Establishes and governs delivery method standards 

► Tracks execution across overall project portfolio 


2.5.2 Required skills and experience 

Table 2-8 describes skill and experience levels for each role. 


Table 2-8 Skills and experience levels 


Role 

Required skills and experience 

"V 

Executive Sponsor 

► Is respected as a senior leader in the organization 

► Understands the organization's strategic direction 

► Has direct influence in the organization's current governance 
committees and processes 

► Has experience championing broad organizational change 

^§j 

Business Architect 

► Has experience with process design, requirements-gathering 

► Has process decomposition and facilitation skills 

► Uses critical analysis and reporting skills 

► Has exposure to Six Sigma and lean methods, financial analysis 
tools, and change management 

i 

BPM Technical 
Architect 

► Has experience with process design and change management 

► Is respected as a senior technical leader in the organization 

► Has experience with iterative and agile methodology or other 
similar methods that are based on rapid application 
development (RAD) 

► Is aware of and has direct influence on the overall enterprise IT 
strategy 

► Has experience championing enterprise technical change 

C A 

BPM Strategy Lead 

► Has experience with software development leadership 

► Has experience with enterprise wide change management 

► Has experience with iterative and agile methodology or other 
similar RAD-based methods 

► Has experience with Microsoft Project and process modeling 
tools 

► Is typically a full-time commitment 
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2.5.3 Organizational structure 

Figure 2-5 and Figure 2-6 illustrate a preferred organizational structure for the strategy 
element of a BPM CoE. 



Figure 2-5 Center of Strategy organizational structure 
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Figure 2-6 BPM CoE organizational structure for the strategy element 


We suggest that at least one distinct person be assigned accountability for each role, and that 
individuals must have prior relevant delivery capability even if they are not assigned delivery 
responsibility. 
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Delivery 


This chapter describes the key focus area of delivery in a BPM Center of Excellence. This 
chapter contains the following topics: 

► 3.1 , “Purpose of delivery in a BPM CoE” on page 28 

► 3.2, “Areas of responsibility for delivery in a BPM CoE” on page 28 

► 3.3, “Success metrics for Delivery in a BPM CoE” on page 28 

► 3.4, “Organization of delivery in a BPM CoE” on page 29 

► 3.5, “Areas of responsibility in depth” on page 29 

► 3.6, “Organization in depth” on page 37 
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3.1 Purpose of delivery in a BPM CoE 


BPM software today is more business friendly than ever, involving the business audience in a 
direct manner during the implementation process. However, the software still requires a team 
of implementation experts to create a fully functional BPM solution. 

After the Center of Strategy determines the vision, the goals, and a road map for the 
enterprise BPM initiative, a delivery organization needs to be dedicated to realizing that vision 
by way of implementing a steady stream of funded BPM projects from the inventory. This is 
the mandate of the BPM Center of Delivery. 


3.2 Areas of responsibility for delivery in a BPM CoE 

Broadly, the domains of concern that fall under the delivery component of a BPM CoE can be 
organized as follows: 

► Scalable staffing and execution of individual BPM projects 

► BPM delivery and implementation focused methodology, best practices, guidelines, and 
reviews 

► Support for operational BPM solutions 

► BPM talent recruitment, enablement, and retention 

In addition to instituting definitions of each of these domains, the BPM CoE must engage in 
activities that advance and implement them. 

For an in-depth view of these domains, see 3.5, “Areas of responsibility in depth” on page 29. 


3.3 Success metrics for Delivery in a BPM CoE 

As is true for all organizations, there must be a way to evaluate the effectiveness, success, 
and value by using concrete metrics. In the case of the delivery element of a BPM CoE, 
typical success metrics include the following items: 

► User acceptance and adoption: 

- Number of processes deployed 

- Number of releases deployed 

- Number of opportunities in the project pipeline 

► Solution delivery: 

- On-time 

- On-budget 

- Defect rate 

- Defect resolution time 

► Reuse: 

- Process reuse rate 

- Service reuse rate 
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3.4 Organization of delivery in a BPM CoE 


After these areas are specifically identified and given concrete articulation, it becomes 
important to give shape to the actual organization that will advance the areas of responsibility. 
This organization can be envisioned in the following typical areas: 

► Roles 

► Skills 

► Organizational Structure 

For an in-depth view of these areas, see 3.6, “Organization in depth” on page 37. 


3.5 Areas of responsibility in depth 

This section describes the following topics: 

► Scalable staffing and execution of individual BPM projects 

► BPM delivery methodology 

► Support of BPM Solutions 

► BPM talent management 


3.5.1 Scalable staffing and execution of individual BPM projects 

One of the primary areas of responsibility for the delivery element of a BPM CoE is to provide 
the staffing, expertise, and experience required to execute on the pipeline of projects built by 
the strategy element of the BPM CoE. This area requires a staffing model and a resource 
pool, aligned with roles in the BPM methodology. 

Staffing model 

The staffing model is the engagement mechanism by which individual projects can make 
requests for resources to implement their process. The purpose of the staffing model should 
go beyond simply supplying tactical skills needed to add discrete functionality to individual 
solutions, to assuming responsibility for the overall success of the BPM solution. 

Any staffing model for BPM projects should take into account a need for scalability to keep 
pace with BPM adoption across the enterprise. This scalability can be enabled by 
understanding the specialization of various roles involved in successfully implementing a 
BPM project, and the recommended level of involvement by these roles in each project. 
These resources are likely to start being used for multiple projects as resource demands grow 
for the BPM CoE. A high degree of usability across projects is the primary value of a 
centralized BPM delivery organization. 

Resource pool 

The types of roles that are resourced through the staffing model should be aligned with the 
BPM Delivery Methodology described in Scaling BPM Adoption: From Project to Program 
with IBM Business Process Manager, SG24-7973 (see the following link), and include the 
roles described in the following sections. 

http://www.redbooks. i bm.com/abstracts/sg247973.html 
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BPM Program Manager 

A methodology coach who provides oversight in the area of driving iterations, playbacks, 
estimation, planning engagement methodology, and agile development in general. Initially, 
this role can also provide traditional Project Management skills (such as contract 
management, time tracking, expenses, and other administrative tasks). However, the real 
value of this role is in driving and owning the methodology and lifecycle of each project. 

Longer term, each organization has to make a decision about whether to combine the 
administrative and methodology responsibility in one role or to separate them out. From a 
methodology coach perspective, this role is recommended at a minimum of 50% involvement 
for each individual BPM project. 

BPM Analyst 

A BPM Analyst focuses on discovering and modeling value-driven process requirements 
within the context of an individual project and with the intent of collaborating with the solution 
implementation team. This role is heavily involved in initial process definition and leading 
process owners and subject matter experts (SMEs) to consensus. The BPM Analyst coaches 
the business participants to deliver Playback Zero and looks for ways to accelerate business 
value through process optimization. For more information, see 5.3.1 “Playback planning” 
in Scaling BPM Adoption: From Project to Program with IBM Business Process Manager, 
SG24-7973: 

http://www.redbooks.ibm.com/abstracts/sg247973.html 

By following the “Playback 0” section in that book, involvement can be reduced to being 
present in, but not driving, each subsequent playback, basically serving as the voice of the 
customer in those gatherings. The value of this role is in driving, discovering, and 
documenting process requirements to prepare for implementation by engaging directly with 
the business and staying lightly engaged to ensure adherence to the BPM solution value 
proposition. 

BPM Developer 

A BPM implementation expert who is trained and experienced in using the BPM platform to 
develop solutions. The key value of this role is to drive toward a release by using the BPM 
methodology and focus on ready-to-use product rather than custom development done 
outside the tool (or unsupported development done inside the tool). This role inherits the 
requirements for the solution from the BPM Analyst at the end of Playback Zero, and is then 
responsible for shepherding the team through the remainder of the playbacks. 

A senior member of this role is typically in a team lead or solution architect role for one or 
more projects, and a junior or mid-level member typically acts in a capacity of individual 
contributor on single projects. 

The BPM Developer role should have a 100% involvement for each individual BPM project, 
although multiple people will likely be in this role for each project. 

BPM Integration Developer 

The BPM Integration Developer is a more technically focused version of the BPM Developer 
role. The BPM Developer focuses on ready usage; the Integration Developer focuses on 
building additional functionality outside the core product that is needed to complete the 
end-to-end solution. In some cases, this focus might mean developing a custom integration 
connector that is not supplied as ready-for-use, troubleshooting any issues with using ready 
for use connectors, developing custom interfaces (beyond the ready-for-use business user 
interfaces in IBM BPM) when there is a valid business, and so forth. The key value of this role 
is handling the IT-driven technical requirements for the project, allowing the BPM Developer to 
focus on addressing the business scenario with ready-for-use functionality. 
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The involvement of this role is highly dependent on the amount of custom development 
required for a project. For a project with no customizations or no new external integrations, 
the involvement can be as low as 30% (to ensure correct usage of existing integrations). On 
the other hand, for a project with custom user interfaces and new integrations to a number of 
external systems, it can be as high as 100% with multiple Integration Developers. As an 
aside, the latter projects are to be strongly scrutinized as appropriate fits for BPM. 

These roles can exist across a spectrum of experience, expertise, and involvement, implying 
varying levels of ownership and responsibility on the project. This information is called out 
specifically to reduce unnecessary middle-management in projects, thus a Team Lead, 
Solution Architect, or Lead Analyst must still align with and perform (with some portion of their 
time) one of the roles described previously. 

Other roles that are resourced from outside the BPM CoE delivery capability 

As a matter of pragmatism, a successful BPM project needs more roles than the roles 
described previously. However, these roles do not need to be resourced by the delivery 
capability of BPM CoE and may be provided by other traditional parts of your IT organization. 

► From the Shared Infrastructure group (see “Organization in depth” on page 54). 

- BPM System Administrator 

► From your traditional IT organization 

- Database Administrator 

- Infrastructure Administrator 

- Overall Enterprise Architect 

- Architects and developers for relevant external systems 

► From the relevant business community 

- Business users 

- SMEs 

- Process owners 
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Figure 3-1 shows the BPM solution delivery team roles. 



BPM shared infrastructure roles: 


I BPM System 
H Admin 

. . ^ 


Other supporting roles: 


Database 

Admin 



System 

Integration 



Owner 



Figure 3- 1 BPM solution delivery team roles 


3.5.2 BPM delivery methodology 

In addition to the staffing model and role resourcing responsibility, another prime area of 
responsibility for the delivery element of a BPM CoE is to actively monitor, manage, and drive 
delivery quality throughout the organization. This area means going beyond simply putting 
trained people on projects and relying on existing traditional IT methods for ensuring quality 
solutions. The BPM CoE must go further and establish its own BPM quality governance 
measures, which should be embodied in a tailored methodology that includes the concepts 
described in this section. 

A BPM project lifecycle model 

The BPM project lifecycle model should be an end-to-end view of implementing a typical BPM 
solution, from funding to discovery, and to deployment and then to support. The 
recommended methodology for BPM projects, which is described in Scaling BPM Adoption: 
From Project to Program with IBM Business Process Manager, SG24-7973, provides a 
helpful starting point that you can tailor to fit your organization: 

http://www.redbooks. i bm.com/abstracts/sg247973.html 

Tactical best practices and guidelines 

A methodology often sets the high-level milestones and vision for the lifecycle of a project. 
However, additional guidelines are often necessary to inform the daily work. 
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Best practices 

A best practice is a set of fit-for-purpose recommendations that can apply in a range of 
situations, without having a specific home in the methodology timeline. Examples are as 
follows: 

► Have the business sponsor for the process lead each playback. 

► Plan each release in 90-day increments. 

► Use a “camel case” naming convention 1 for variables inside the implementation tool. 

These best practices can be grouped in a number of ways, including a planning focus, an 
analysis and business-engagement focus, and a technical focus. IBM BPM Community's 
BPM Implementation Best Practices are a helpful starting point to this body of knowledge: 

http : //bpmwi ki . bl ueworksl i ve. com/di spl ay/commwi ki /Best+Practi ces+Recommendati ons 

Guidelines 

In some cases, a guideline is needed instead of a rule. Guidelines can act as “sign posts” or 
early warning systems, rather than reflexive actions without contextual critical thinking. For 
example, the following guideline often points to a misunderstanding about how to model 
processes: 

Avoid a sequence of activities adjacent to each other in the same swimlane 

However, in some cases, this action might be the correct one if the author is documenting the 
as-is process with a view toward future improvements through better work distribution. 
Guidelines are sometimes combined with best practices; the pertinent difference is 
suggestive versus prescriptive. 

Design patterns 

In some cases, curating and advocating reusable patterns of implementation and design is 
important because they can dramatically increase productivity in both design and 
implementation. Although some design patterns are domain-specific and must be discovered, 
evolved, and recorded as your BPM CoE matures, others are domain-independent and can 
be used immediately. IBM BPM Community's suggested BPM Design Patterns are a helpful 
starting point to this library: 

http : //bpmwi ki . bl ueworksl i ve. com/di spl ay/commwi ki /Desi gn+Patterns 

Toolkits 

It is often necessary to go beyond theoretical design patterns and actually build executable 
reusable assets that can be used for commonly occurring work across multiple processes. 
For instance, you might want to develop a Toolkit for Accounting System Integrations, or SAP 
integrations or Customer Lookup. Most toolkits tend to be thematically focused on various 
ways of talking to a single external system at a time, or encapsulating a commonly occurring 
design pattern or widget. Similar to design patterns, although some toolkits are specific to a 
domain and certainly an organization, several can be independent of those factors and used 
as utilities. 

IBM BPM Community's BPM Toolkits are a good starting point to reference in your BPM CoE 
library of toolkits: 

http : //bpmwi ki . bl ueworksl i ve. com/di spl ay/sampl es/Tool ki ts 


1 Camel case is a word or string of letters that has no space and has an upper case letter in a position other than the 
first letter, for example dataType. 
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Project reviews 

The BPM CoE responsibilities start with the curation and organization of all the assets 
described previously, but they should not end there. In fact, the entire purpose of having a 
methodology (with lifecycle, best practices, guidelines, and toolkits) is to proactively assert its 
appropriate usage within each individual project executed by the BPM CoE. This assertion 
should be done by applying regular and consistent project reviews, or health checks, which 
aim to measure the likelihood of success for each project at distinct stages in the lifecycle. 

To produce consistent results from project reviews, develop a “BPM Delivery Quality 
Assessment” framework. This framework should have standard questionnaires and templates 
that provide delivery health indicators along with remediation measures for improvement. In 
essence, it is a check to determine how closely the project team adheres to the known best 
practices, guidelines, toolkits, and patterns discussed previously. 

IBM Software Services for BPM offers a formal Health Check engagement for your BPM 
project that can serve as a good starting point for your own BPM Delivery Quality Assessment 
framework. Contact your IBM sales representative to learn more about these services 
engagement offering. 


3.5.3 Support of BPM Solutions 

After the BPM CoE successfully executes and deploys a BPM Solution, it should also provide 
continued support that is specific for business process owners and participants. Although 
technical support and administration activities can be done by traditional IT groups and the 
shared infrastructure group, business functionality and solution support should be bolstered 
by a BPM-specific support team. This BPM solution support team should apply product 
expertise to support the solution at a Level 3 tier, such as in the following examples: 

► How to interpret product specific behavior, read logs, use BPM specific tools to 
troubleshoot problems 

► Be aware of the business purpose of various solutions, and so on 

A beneficial approach is to rotate members of the project implementation team through 3 - 6 
months of support engagement to help the team members develop well-rounded perspectives 
in implementing better solutions. 

The success of the BPM solution support organization should be measured by percent of 
user adoption, amount of business rework as a result of errors, and interruptions of business 
continuity. Traditional measurements of support organizations, such as number of bugs 
resolved or time spent to close issues, does not measure business value in any meaningful 
way and can get lost in operational efficiency, divorced from true business value. 


3.5.4 BPM talent management 

The BPM CoE is responsible for the human resource talent in a BPM program. The BPM CoE 
must recruit, enable, and retain the people and skills that are needed to support the 
transformational and growing BPM program initiatives, guided and set by the strategic 
component of the BPM CoE. 

Recruiting 

In recruiting BPM delivery talent, each individual role must be specifically targeted. An 
important note is that the first three roles are generally not successful transitions from 
traditional IT. Successful BPM talent comes from people who are first and foremost 
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passionate about discovering, understanding business problems (rather than administrative, 
operational, documentation, or technical problems). 

Table 3-1 describes the roles and responsibilities for recruiting. 


Table 3- 1 Recruiting roles and responsibilities 


Role 

Responsibilities 

Skills (for mid-level) 

BPM Program 
Manager 

► Is an expert in Iterative Delivery 
Methodology 

► Drives team to produce 
measurable business value 

► Identifies and mitigates risks 

► Acts as conduit for escalations and 
issue resolution 

► Provides internal and external 
status and dashboards 

► Manages scope, budget, and 
resources 

► 3-5+ years of hands-on 
experience with iterative (or other, 
similar) methodology 

► 3-5+ years of experience with 
leadership in software 
development projects 

► Experienced user in process 
discovery tools (for example, 
Blueworks Live) 

► User of Microsoft Office, Microsoft 
Project, Process Design tools 

► Prior BPM project experience 

BPM Analyst 

► Leads process improvement 
efforts 

► Is an expert in process 
decomposition, process/data 
analysis, scoping, optimization 

► Identifies business case, key 
opportunities, prioritized roadmap, 
and ROI 

► Identifies and enforces delivery of 
KPIs, SLAs, and scoreboards 

► Identifies and captures as-is and 
to-be process information in 
discovery tools 

► 3-5+ years of experience with 
process design, requirements 
gathering 

► Process decomposition facilitation 
skills 

► Critical analysis and reporting 
skills 

► Exposure to Six Sigma or Lean 
methods, financial analysis tools 
and change management 

► Power user of BPM Discovery (for 
example, BlueworksLive) tools and 
be familiar with process diagrams 
in BPM tools 

BPM Developer 

► Implements process flows, 
services, business logic, and user 
interfaces within the BPM product 

► Is an expert in BPM product 
features in the context of business 
solutions 

► Implements KPIs, SLAs, and 
scoreboards within the BPM 
product 

► Drives business playback sessions 

► 3-5+ years of experience with 
technical solution development on 
commercial or enterprise projects 

► Hands-on implementation 
experience with JavaScript, basic 
SQL, XML, HTML 

► Experienced at workflow patterns 
and basic logic flows, user 
interface development 

► BPM product expert 

BPM Integration 
Developer 

► Is responsible for systems 
architecture regarding the solution 

► Designs and implements 
integrations, custom data storage, 
and complex data manipulations. 

► Guides infrastructure design and 
implementation pertinent to the 
solution 

► 5-7+ years experience with 
software development projects. 

► Experience in architecture 
planning and development 
projects 

► Hands-on implementation 
experience with J2EE, Java, JSP, 
SQL, SOAP, XML, XSLT, patterns, 
advanced logic flows, EAI, .NET 

► Integration expert 
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Enablement 

When new members are hired to the delivery team, they must go through a BPM enablement 
process (beyond the basic onboarding items for all new employees). 

Channels 

In most cases, enablement takes the form of four channels: 

► Standard or self-paced product training 

The purpose of this channel is to serve as a basic primer, meant to introduce the relevant 
product and methodology to the individuals in these roles. In the case of IBM BPM, a wide 
range of educational courses are available: 

http://www.i bm.com/software/websphere/education/curri cul um/bpm/ 

► Reference and documentation material 

Use this channel only after the basic training is completed. The channel assumes that 
individuals already know the basic ecosystem of the tools and methodology they will be 
working with, and now have advanced, specific questions they want to explore on their 
own. If using IBM BPM, see the reference and documentation material: 

http://www.i bm.com/devel operworks/websphere/zones/bpm/ 

► Internal workshops and seminars 

After standard knowledge about the tools and their related methodology is absorbed by 
the participants, an essential step is to update that information with how it is to be applied 
in your organization. What is standard in the courses and documentation may not be 
standard you chose to follow in your organization. All such contextual knowledge about the 
application of BPM in your organization (from conventions, best practices, guidelines to 
the CoE itself) should be provided to the individuals in these roles in the form of a regular 
internal workshop meant to be consumed by all new additions to the team. 

These workshops can be delivered ad-hoc, or recorded and made available as self-paced 
material, in which interpretation and contextual critical thinking are essential. 

► Short, targeted, boot camps 

Training, documentation, workshops, and seminars are for the most part a passive means 
of absorbing information. After this first set of information is delivered, it can be put into 
practice by actively doing work in an environment that has a specific time period and 
controlled risk. 

This type of active learning can be done through BPM boot camps, which provide 
packaged projects and exercises for the participants, and with a dedicated boot camp 
“track lead” to help the participants apply and use their existing knowledge to implement 
their boot camp projects. 

The primary purpose of boot camps is to provide a learning experience for the 
participants, for example, learning the tool and in applying the methodology. A secondary 
purpose at later stages of maturity for the BPM CoE might also be to jump-start actual 
BPM projects that will be deployed to production. Selecting such projects and crafting their 
first phase to fit within the boot-camp curriculum and timeline delivers real business value, 
although internal skills enablement is ongoing. 

Limited mentoring period 

Following the boot-camp experience, your new team members are now ready to be staffed on 
BPM projects under the guidance of the BPM CoE. An important note, however, is that each 
graduate from this program will need mentoring by a more experienced individual. The 
mentoring period can be adjusted based on the individual, the nature of the first project the 
person is assigned to, and the role this person is fulfilling on that project. However it is 
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facilitated, take mentoring seriously; mentoring should be conducted in a formal or structured 
fashion to accelerate achievement. 

The mentoring period provides a real-world crucible in which to evaluate and examine actions 
that might make perfect sense in the controlled education environments, but are in fact to be 
avoided in certain real-world scenarios. The feedback that is received during this time can 
help solidify all the knowledge that is gained so far and enable your team to gain that last bit 
of organizational knowledge, common sense, and critical thinking that is necessary to 
succeed. 

Retention 

An enormous amount of effort goes into recruiting and enabling the members of the BPM 
CoE. The CoE leadership team should be directly responsible for putting in place measures 
to retain these team members as a part of the BPM delivery practice and to align their internal 
career growth with growth in their BPM delivery roles. One of the most common problems in 
any CoE is the continuous leaving of qualified individuals that comes with having learned new 
and valuable skills and a perceived lack of rewarding opportunities in which to apply those 
skills. 

The BPM CoE represents a substantial investment for the organization and the executive 
sponsor’s office. It is incumbent upon the element of the CoE responsible for leadership in 
delivery to protect and provide a return on that investment. 


3.6 Organization in depth 

The organization of the BPM CoE requires specific skills, envisioned in roles that are then 
organized in a decision-making and executing structure against their areas of responsibility. 

3.6.1 Roles 


Similar to the strategy element in the BPM CoE, a useful way to think of the roles that are 

involved in creating a delivery practice is as follows: 

1 . Start with a core group. 

2. Later, expand into a scalable set of roles (some are likely to be specific to your 
organization) that support this core group. 

Core roles 

This section defines the core roles for the delivery element of the BPM CoE. 

Executive Sponsor 

This role is the highest level executive who has responsibility for (most likely, in the form of 

direct ownership) the BPM delivery initiative. 

► Provides senior leadership. 

► Sets the direction for the delivery of BPM projects. 

► Establishes and evolves the funding model along with this Executive Sponsor’s 
counterpart for BPM strategy. 

► Governs escalation processes along with this Executive Sponsor’s counterpart for BPM 
strategy. 

► Socializes and advocates for the BPM CoE as the de facto delivery team for all BPM 
projects across the enterprise. 
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Center of Delivery Lead 

This role is typically a senior and proactive Project Manager who has experience in running 
wide ranging initiatives with several simultaneous projects. This person is familiar with the 
BPM methodology used in implementing individual projects. Typically, this role is a full-time 
commitment. 

► Establishes, documents, and governs the BPM project pipeline. 

► Establishes and governs the staffing model for addressing the pipeline. 

► Runs year-long recruiting, enablement, and retention initiatives to grow the delivery team 
at a rate that can sustain the growing demand for BPM projects and initiatives in the 
enterprise. 

► Establishes and governs measurement standards for BPM delivery 

► Tracks execution across overall project portfolio. 

BPM Program Management Competency Lead 

This role is typically a senior Project Manager who has experience with large projects, 
establishing a methodology and providing governance along with quality control across 
multiple projects. Typically, this role is a full-time commitment. 

► Estimates, plans, and manages the overall BPM project. 

► Creates, manages, and drives the BPM Project Methodology within the BPM CoE. 

► Enables the delivery team with agile methodology and a business-value focus. 

► Leads the BPM Program sub-team and is a member of this sub-team. 

BPM Analysis Competency Lead 

This role is typically a senior BPM Analyst who has experience with large projects, 
establishing a comprehensive analysis methodology (similar, although not the same as, 

Six Sigma and Lean) and providing analysis mentorship for junior and mid-level BPM 
Analysts across multiple projects. Typically, this role is a full-time commitment. 

► Is responsible for discovery and documentation of BPM requirements 

► Creates, manages, and drives the BPM analysis methodology within the BPM CoE 

► Enables the business with process analysis and management capabilities. 

► Leads BPM Analysis sub-team and is a member of this sub-team. 

BPM Solution Development Competency Lead 

This role is typically a senior BPM Developer who has experience with leading teams and 
doing hands-on solution implementation work (writing solution code) for large projects. This 
person also has experience in establishing a comprehensive solution development 
methodology and provides implementation mentorship for junior and mid-level BPM 
Developers across multiple projects. Typically, this role is a full-time commitment. 

► Is responsible for implementation of BPM requirements within BPM tool for individual 
projects. 

► Creates, manages, and drives the BPM Solution Development methodology, guidelines, 
and best practices within the BPM CoE. 

► Enables the business with process analysis and management capabilities. 

► Leads the BPM Solution Development sub-team and is a member of this sub-team. 
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BPM Technical Development Competency Lead 

This role is typically a senior Technical Developer who has experience with leading and 
implementing large integration and back-end projects. This person also has experience in 
establishing a comprehensive integration development guidelines and providing 
implementation mentorship for junior and mid-level Integration Developers across multiple 
projects. Typically, this role is a full-time commitment. 

► Is responsible for implementation of technical requirements for BPM solution (outside the 
BPM tool) for individual projects. 

► Creates, manages, and drives the BPM Integration Development methodology, guidelines 
and best practices within the BPM CoE. 

► Enables the delivery team with required toolkits and integrations. 

► Leads the BPM Technical Development sub-team and is a member of this sub-team. 

Scalable roles 

This section defines the scalable roles for delivery element of a BPM CoE. 

BPM Program Manager 

This role is typically a Project Manager who has experience with medium to large projects, 
driving a methodology, and providing project-level governance along with quality control 
across multiple projects. Typically, this role is a full-time commitment. 

► Estimates, plans, and handles overall management of the BPM project. 

► Drives the BPM Project Methodology within the project. 

► Enables the delivery team with agile methodology and a business-value focus. 

BPM Analyst 

This role is typically a Business Analyst who has experience with process decomposition in 
medium to large projects, driving a comprehensive analysis methodology (similar to, although 
not the same as, Six Sigma and Lean) for individual projects. Typically, this role is a full-time 
commitment. 

► Is responsible for discovery and documentation of BPM requirements within the project. 

► Drives the BPM Analysis methodology within the project. 

► Enables the business with process analysis and management capabilities. 

BPM Solution Developer 

This role is typically an available Solution Developer who has experience with using packaged 
solution development software, doing hands-on solution implementation work (writing solution 
code such as JavaScript, XML, SQL, and so on) for medium to large projects. This person 
also has experience in driving a comprehensive solution development methodology for a 
project. Typically, this role is a full-time commitment. 

► Is responsible for implementation of BPM requirements within the BPM tool for the project. 

► Drives the BPM Solution Development methodology, guidelines, and best practices within 
the project. 

► Enables the business with process analysis and management capabilities. 

BPM Technical Developer 

This role is typically a Technical Developer who has experience with implementing medium to 
large integration and back-end projects, doing hands-on functional implementation work 
(writing functional code such as Java and .Net), and has solid experience with the back-end 
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stack of the IT organization. This person also has experience in driving comprehensive 
integration development guidelines for multiple projects. Typically, this role is a full-time 
commitment. 

► Is responsible for implementation of technical requirements for BPM solution (outside the 
BPM tool) for a project. 

► Drives the BPM Integration Development methodology, guidelines, and best practices 
within a project. 

► Enables the delivery team with required toolkits and integrations. 


3.6.2 Required skills and experience 

This section describes the skill and experience levels for each of the core and scalable roles. 


Core roles 

Table 3-2 describes skill, experience, and commitment levels for the core roles. 


Table 3-2 Core skills and experience levels 


Role 


Required skills, experience, and commitment 


I 

| 

Executive Sponsor 


fts 


Center of Delivery 
Lead 


BPM Program 
Management 
Competency Lead 





BPM Analysis 
Competency Lead 


Is respected as a senior leader in the organization 
Understands and embraces the delivery organization’s strategic 
mission 

Has direct influence in the IT organization’s current governance 
committees and processes 

Experience leading large specialized delivery teams 
Role is typically a part-time commitment 

Experience with project management and staffing 
Experience with project pipeline management and growth 
Experience with creating and applying various delivery models 
depending on the pipeline need 

Exposure to Six Sigma and Lean methods, financial analysis tools and 

change management 

Role is typically a full-time commitment 

Experience with agile and iterative project management and 
methodology development 

Experience with Six Sigma or Lean methods, financial analysis tools 

and change management 

Experience with software development leadership 

Experience in mentoring and teaching other agile program managers 

Role is typically a full-time commitment 


Experience with business analysis methodology development and 
leadership 

Experience with enterprise change management 
Familiarity with iterative and agile methodology or other similar 
RAD-based methods 

Experience with process design, requirements discovery and capture 
(and relevant tools) 

Process decomposition and facilitation skills 
Critical analysis and reporting skills 
Role is typically a full-time commitment 


40 Creating a BPM Center of Excellence (CoE) 


Role 

Required skills, experience, and commitment 

BPM Solution 
Development 
Competency Lead 

► Experience with solution development leadership 

► Experience with developing an iterative and agile methodology or other 
similar RAD-based methods 

► Experience with process design, requirements refinement 

► Process decomposition and facilitation skills. 

► Hands-on programming skills: JavaScript, XML, SQL, HTML 

► Role is typically a full-time commitment 

BPM Technical 
Development 
Competency Lead 

► Experience with technical and functional development leadership 

► Experience with developing an iterative and agile methodology or other 
similar RAD-based methods 

► Hands-on programming skills: Java, .NET 

► Experience with organizations back-end software stack and SOA 

► Role is typically a full-time commitment 


Scalable extended roles 

Table 3-3 describes skill, experience, and commitment levels for the scalable extended roles 
Table 3-3 Scalable extended skills and experience levels 


Role 

Required skills, experience, and commitment 

4P 

► Experience with applying agile and iterative project management and 
methodology 

► Experience with Six Sigma or Lean methods, financial analysis tools 
and change management 

BPM Program 
Manager 

► Experience with software development leadership on individual 
projects 

► Role is typically a full-time commitment 


► Experience with applying and driving a consistent business analysis 
methodology 

► Familiarity with iterative and agile methodology or other similar 
RAD-based methods 

BPM Analyst 

► Experience with process design, requirements discovery and capture 
(and relevant tools) 

► Process decomposition and facilitation skills 

► Critical analysis and reporting skills 

► Role is typically a full-time commitment 

t 

BPM Solution 
Developer 

► Experience with solution development 

► Experience with applying a iterative and agile methodology or other 
similar RAD-based methods 

► Experience with process design, requirements refinement. 

► Process decomposition and facilitation skills. 

► Hands-on programming skills: JavaScript, XML, SQL, HTML 

► Role is typically a full-time commitment 

c © 

► Experience with technical and functional development 

► Experience with applying an iterative and agile methodology or other 
similar RAD-based methods 

BPM Technical 
Developer 

► Hands-on programming skills: Java, .NET 

► Experience with organizations back end software stack and SOA 

► Role is typically a full-time commitment 
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3.6.3 Organizational structure 

This section describes the suggested organizational structures for the Center of Delivery. 

Core 

Figure 3-2 shows the organizational structure for the core roles. 



Center of Delivery 
Lead 



BPM/Rules Analyst 
Competency Lead 



Center of Delivery 
Sponsor 



BPM Technical 
Development 
Competency Lead 



BPM Program Manager 
Competency Lead 



BPM Solution 
Development 
Competency Lead 


Figure 3-2 Core roles organizational structure 
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Scalable 

At least one distinct person should be assigned the accountability for each role. That person 
must have prior relevant delivery capability even if the person is not assigned delivery 
responsibility. Figure 3-3 shows the organizational structure for the scalable extended roles. 




Center of Delivery Sponsor 


Center of Delivery Lead 


BPM/Rules Analysis 
Competency Lead 



BPM/Rules Analysts 

BPM Program Management 
Competency Lead 


BPM Program Managers 



BPM/BRM Technical 
Development 
Competency Lead 



BPM Technical Developers 


BPM Solution Development 
Competency Lead 


BPM Solution Developers 


Figure 3-3 Scalable roles organizational structure 

Figure 3-4 shows a composition view of a Solution Team. 


BPM Program 
Manager 


c n 


BPM/Rules 

Analyst 


BPM 

Solution 

Developer 

BPM 

Technical 

Developer 




Solution Teams 


Solution A 


Solution B 


Solution ... 


Release scoping and definition 
Build and test 
Deployment and support 


Solution risk management 
Communication and training 
Measurement and optimization 


Figure 3-4 Composition of roles 


At least one distinct person should be assigned the accountability for each role. That person 
must have prior relevant delivery capability even if the person is not assigned delivery 
responsibility. 
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Shared infrastructure 


This chapter describes the key focus area of the shared infrastructure in a BPM Center of 
Excellence. This chapter contains the following sections: 

► 4.1 , “Purpose of shared infrastructure in a BPM CoE” on page 46 

► 4.2, “Responsibility areas for shared infrastructure in a BPM CoE” on page 46 

► 4.3, “Success metrics for shared infrastructure in a BPM CoE” on page 47 

► 4.4, “Organization of shared infrastructure in a BPM CoE” on page 47 

► 4.5, “Areas of responsibility in depth” on page 47 

► 4.6, “Organization in depth” on page 54 
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4.1 Purpose of shared infrastructure in a BPM CoE 


Even the simplest BPM solution has the potential to have a major impact on your 
organization. Companies are often surprised that a successful pilot or proof-of-concept 
business process application can quickly become mission-critical. When you fully embrace 
BPM, you should understand the implications; the processes you create, automate, and 
deploy run your core business. Without a solid platform and practices, your users become idle 
and your business comes to a halt. Therefore, when you build the initial BPM platform, it must 
be scalable, available, and secure, and be sized appropriately to address your foreseeable 
load. 

One of the initial steps of planning for the shared infrastructure element of BPM is to design 
the eventual platform that will host the BPM system (BPMS) and its various process 
applications. This step can be difficult because, at this early stage, you might not have firm 
requirements for the various process applications (built on the BPM platform) you will 
implement, deploy, and maintain on the BPMS. Nevertheless, your shared infrastructure must 
handle initial process application development and scale to support user adoption of initial 
process applications and also expansion for new process applications. This endeavor can be 
demanding for the individuals who are responsible for creating a BPMS for those first 18 
months. 

This section describes the shape of the organization that is in charge with building the shared 
infrastructure, and the organization’s areas of influence, and roles and skills. 


4.2 Responsibility areas for shared infrastructure in a BPM CoE 

Areas of responsibility for the shared infrastructure element of a BPM CoE include the 
following key focus topics, with respect to the BPMS platform that is necessary for 
implementing, deploying, monitoring, and improving business process applications. 

► Availability 

► Performance 

► Scalability 

► Security 

► Application governance 

In addition to defining these areas, the shared infrastructure element of a BPM CoE must also 
engage in activities that continuously advance and implement them. 

Ultimately, at a lower level, this group (shared infrastructure element) is responsible for areas 
such as hardware, the continuous “greening” of platforms, administration, deployments, and 
many traditional IT areas. However, all of these tactics must ultimately support one of the 
goals in the previous list. The purchase of four rather than six servers is not the goal; the goal 
is guaranteeing 95% availability. 
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4.3 Success metrics for shared infrastructure in a BPM CoE 


The success metrics of this shared infrastructure organization are similar to most traditional 
IT success metrics that handle shared infrastructure for enterprise platforms. The key 
difference is that this organization focuses on the success of the business solutions that are 
hosted on these platforms, and not only the platform itself. 

The success metrics are as follows: 

► Solution uptime/availability 

► Solution responsiveness 

► Scalability of operational services including logging and error handling 


4.4 Organization of shared infrastructure in a BPM CoE 

After these areas (listed in 4.2, “Responsibility areas for shared infrastructure in a BPM CoE” 
on page 46) are specifically identified and given concrete articulation, the next important step 
is to give shape to the actual shared infrastructure organization that will advance the areas of 
responsibility. This organization can be envisioned along the following typical areas: 

► Roles 

► Skills 

► Organizational Structure 


4.5 Areas of responsibility in depth 

One of the initial steps of planning for a BPM Center of Excellence is to design the eventual 
platform that will host your BPM process server. This step can be difficult because at this 
early stage, you might not have firm requirements for the applications that you will host. A 
BPM CoE must prepare to support current process applications and plan to expand the 
BPMS to support future applications. 

This chapter offers a system outline that can give you enough initial system capacity, which 
you can scale to meet the future demand successfully. 


4.5.1 Availability 

Availability is related to the concept that our platform can survive system level failures. 
Availability is a measure of the time that a system is functioning normally, and also a 
measure of the time the recovery process requires after a system component fails. Reducing 
downtime is the most critical aspect of highly available systems. A highly available system is 
therefore one that can quickly recover from system failures and can show little or no impact to 
users during such events. Availability depends on the ability of replicated components to 
efficiently fail over. 

IBM BPM is built on IBM WebSphere Application Server. Therefore, IBM BPM benefits from 
the inherent availability characteristics and capabilities of WebSphere Application Server and 
can benefit from the years of experience IBM invested in building highly available systems. 
This paper does not provide details of high availability concepts for WebSphere Application 
Server, but attempts to bring attention to those system components that might require 
additional consideration when building a highly available BPM CoE platform. More information 
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about WebSphere Application Server availability is in WebSphere Application Server Network 
Deployment V6: High Availability Solutions, SG24-6688: 

http : //www. redbooks . i bm.com/redbooks/pdfs/sg246688.pdf 

Topology 

The first step is to determine the topology of the deployment. Topology often indicates 
availability. Topology can include clustering, load balancers, web servers, proxies, database 
replication, and other items. Regardless of system load, you want to create an environment 
that can sustain quality of service, even in the event of a component failure. 

IBM BPM provides a network deployment installation option, sometimes called the golden 
topology, that provides a high level of availability. A network deployment environment contains 
a collection of interconnected servers and clusters to run your business process applications. 

Clustering across more than one node provides availability in the event that a node stops for 
any reason. A best practice is to have nodes running on separate hardware, or separate 
LPARS or VMs that are running on separate hardware, to ensure availability in the event of a 
hardware error. 

Mitigating other points of failure 

Availability is not limited to the application tier. There are many other potential areas for failure 
in a typical enterprise application server infrastructure. 

Deploying your BPM platform within an infrastructure that is tolerant to loss of components is 
important. For example, we must be prepared for the loss of an IP sprayer, HTTP server, or 
firewall or router. Building in redundancies for these components can eliminate single points 
of failure and reduce subsequent downtime. 


4.5.2 Scalability 

From the beginning, invest in enough initial system capacity. False economies in the early 
stages can cause exponentially more cost and pain later. A two-node cluster running on 
4-core hardware provides most organizations more than enough initial capacity to handle a 
successful CoE program. 

A goal is to be able to increase system capacity when new intensive process applications are 
onboarded into the CoE and when existing process applications become widely adopted and 
demand more resources. Scalability refers to a system’s ability to readily adapt to these 
increasing demands while still meeting business objectives. Taking scalability into account 
when you initially design a business process management platform is critical. You must select 
appropriate hardware, operating system, topologies, and virtualization technologies to 
optimize your potential to meet future load requirements. 

The two types of scalability are vertical and horizontal: 

► Vertical scalability is the ability to add more resources (cores, CPUs, memory) to gain 
performance. 

► Horizontal scalability is the ability to add more hardware (machines) to gain performance. 

By its nature, the network deployment (ND) option for IBM BPM lends itself to horizontal 
scalability. The clustering of nodes allows you to expand system capacity by adding more 
machines. Ideally, scaling up a topology arbitrarily to match the required load is possible. The 
WebSphere Application Server Network Deployment infrastructure provides this capability. 
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Vertical scalability is more often achieved by using features of the underlying operating 
system or virtual machine. Vertical scalability is an attractive option because it does not 
involve adding servers in response to demand for new capacity and can reduce the need for 
more datacenter space, power, cooling, network cabling, data storage and administrative 
resources. 

Recommending an initial system 

Because you will unlikely know the capacity requirements of all eventual process applications 
that are hosted by your CoE environment at the time it must be designed, the best approach 
might be to simply build a system with known capacity and scalability attributes. With this 
approach, you can grow your environment as required over the life of the process application 
system. 

Although you do not yet know the characteristics of the process applications that will 
eventually be hosted by your CoE environment, you might know about certain aspects of your 
organization. Imagine a scenario where a company has fully embraced BPM and that every 
employee will, in some way, interact with the system. One way to make a rough calculation is 
to consider the maximum number of concurrent users that will ever use the system. In the 
case of a successful BPM program, this number will be every employee. If your BPM program 
is targeted only at a certain department, then it will be every employee of that department. 

Testing revealed that, for a mildly complex process application, 900 concurrent users can be 
supported on a 2-core X86 2.6 GHz system. This system also nicely scales to 1800 users on 
a similar 4-core system. Table 4-1 describes the configurations. 


Table 4-1 System configurations 


Number of users 

Hardware 

Less than 900 

X86 2.6 GHz 2-core 

A range of 900 - 1 800 

X86 2.6 Ghz 4-core 

Greater than 1800 

Several options exist. BPM has demonstrated that it can support more 
than 10,000 concurrent users on an 8-core IBM POWER7® system 
running an IBM AIX® operating system. This way can be combined with 
horizontal scalability to address very large concurrent user requirements. 


Being conservative, if you have fewer than 1000 potential business process users, a 4-core 
system might be an appropriate starting point for your initial CoE platform. 

Recall that there are availability requirements, which are best addressed by having a 2-node 
cluster where the nodes exist on separate hardware. This way effectively doubles hardware 
requirements: instead of having a single 4-core machine, you can have two 4-core machines 
in a cluster. Although this approach can handle twice the load, you should design the system 
so that, in the event of a node failure, the surviving node can handle 100% of the load. 

A 2-node cluster running on 4-core hardware can provide most organizations more than 
enough initial capacity to handle a successful CoE program. 

Medium-term solution-based partitioning 

As the “starter” system begins to mature and take on load from hosting more BPM solutions, 
it might make sense to consider partitioning resources according to specific categorization 
classes (such as criticality, security, region, or department). 

No rule says that all process applications must be deployed to a single process server 
runtime environment. As you approach the capacity of your existing production process 
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server environment, you must consider expanding into multiple production server 
environments. The most natural way to approach this option is to roll new process 
applications into new environments. Other options are to create departmental, regional, or 
security-specific runtime environments. 

In fact, if the expected nature of your foreseeable process applications are strictly 
departmental, now might be the time to make the decision to create departmentally 
partitioned runtime environments. As of BPM 7.5, it is not practical to migrate a business 
process application and all of its in-flight data from one process server to another. Therefore, 
it is even more important to make the correct platform decision now, before you reach a 
capacity issue and have to handle the difficult situation of migrating a process application and 
its data to another platform. 

Long-term capacity planning 

A shared infrastructure BPM deployment will eventually consist of multiple BPM process 
applications. It is important that these applications coexist without affecting the performance 
of their neighbor applications that share the same BPM platform. Your BPM runtime 
environment has finite resources including CPU, memory, network bandwidth, database 
throughput, and I/O capacity. These resources all must be shared by the hosted business 
process applications and must be used in a way that does not introduce performance 
degradations or failures. Therefore, some level of performance testing and capacity planning 
is required to project the potential impact of a new process application into your BPM runtime 
environments. 

A strong suggestion is for a capacity planning exercise to be a part of your business process 
on-boarding practice. Further, business processes are never static; they change over time, 
take different paths based on market, seasonal, and business conditions. By their nature, 
business processes are in a constant state of evolution. Therefore, be sure to make capacity 
planning a regular part of your release cycle. 

A reasonable capacity planning exercise naturally calls for regular capacity testing to discover 
the limits and needs of the existing system against the planned future system. The best 
possible capacity test might be one that exercises every deployed process application 
concurrently. Although it is theoretically possible to concurrently test all process applications 
under a single massive test plan, doing so is not always practical. We are often constrained 
by time, budget, and resources. Compared to testing the entire system of process 
applications, a typical one-process-application BPM deployment is relatively easy to test. This 
chapter introduces a methodology for testing individual process applications and 
extrapolating those results to determine plausible system impact. 


4.5.3 Security 

Your business processes make up an essential part of your business. They incorporate your 
intrinsic intellectual property and make it available, consumable, and usable by your 
workforce. Although it is evident that BPM promotes and provides continuous improvement, 
business agility, and process visibility, there is a price to pay for such benefits. The simple act 
of exposing your processes and data to your users implies a substantial responsibility to 
protect and track that data. 

From a governance perspective, a CoE must indicate how your data and processes are 
protected and how process actions are recorded and can be audited for both legal and 
business requirements. A CoE must establish the infrastructure and practices that will protect 
your intellectual property from both internal and external threats. 


50 Creating a BPM Center of Excellence (CoE) 



You can think of your security concerns as a stack of environments, pertinent to three areas: 
platform, development, and runtime. Table 4-2 provides details. 


Table 4-2 Security environments 


Area 

Description 

Platform 

Chronologically, the platform is the first layer of 
the stack that is put into place. The platform must 
be secured from inappropriate access. Access to 
administrative interfaces must be limited. 

Development 

The next layer to emerge is development. We 
must create permissions that allow developers to 
have access to the code base and application 
administrators to administer the process 
applications. We must allow read-only users 
access to the process application. 

Runtime 

Runtime is a factor. Runtime users must be 
provisioned so that they can be mapped to 
process participant groups. 


You must consider the types of users when you establish enterprise-level BPM security. Each 
type of user has specific access requirements. Table 4-3 provides details. 


Table 4-3 User security requirements 


Users 

Description 

Platform administrators 

Users that are charged with the security and 
availability of the BPM platform. 

Application administrators 

Users that are the technical owners of a business 
process application for its entire lifecycle. 

Application developers 

Users that develop specific business process 
applications. 

Applications business users 

Users that may need read-only access to a 
business process at design time. 

Standard Users 

Users that interact with the business process at 
runtime. 


For details about BPM security, see IBM Business Process Manager Security: Concepts and 
Guidance, SG24-8027: 

http : //www. redbooks . i bm.com/Redbooks . nsf/Redpi eceAbstracts/sg248027 . html ?0pen 


4.5.4 Application governance 

The shared infrastructure group should also be responsible for how process applications are 
deployed to various runtime environments (including production). This responsibility includes 
defining procedures for acceptance, processes for approval to promote into each runtime 
environment, best practices for these actions, and clearly defined roles around them 

In addition, from the perspective of CoE platform support, a goal is to have well-behaved 
process applications deployed in environments. A well-behaved process application requires 
little to no support from the platform team, does not exceed its projected capacity estimates, 
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and does not affect other process applications. Instilling a basic set of coding and process 
architecture best practices can help in meeting these goals. 

One of the overriding goals of the platform team is to promote self-reliance for the process 
teams. The less the process teams have to ask the platform team for information or access to 
resources, the more efficient the process teams can operate. 

Deployment 

In IBM BPM V8.0 and later, you can apply a governance process that provides a control over 
the installation of process applications. When this governance process is in place and 
enabled on a process application, requests that are made from IBM Process Center to install 
a snapshot of that process application, pass through a governance process. The process 
application snapshot is installed on a process server only after the approvals that are defined 
in that governance process are completed. 

You can find a sample governance process application on the IBM BPM Sample Exchange at 
the following location: 

http : //bpmwi ki . bl ueworksl i ve . com/ /x/AoRgAQ 

The shared infrastructure element of the BPM CoE is responsible for defining processes, best 
practices, and roles in the following key focus areas. 

Deployment acceptance criteria 

Define the release criteria for the delivery team to follow so that a process application can be 
deployed on an available runtime environment. These criteria might include minimum 
standards such as installation instructions, use of an export file, standard unit test results, 
standard business information about deployment packages, and so on. 

Deployment execution processes 

What are the steps that must be followed to deploy a candidate snapshot (build) of a process 
application into a target runtime environment? In some cases, this deployment might involve 
certain approval steps from both business and IT. Deployment might also involve 
prerequisites. For example, deployment to user acceptance testing (UAT) might be prohibited 
until after the process application is deployed in QA and accepted by the business process 
owner. 

Deployment rollback processes 

In certain cases, an executed deployment might need to be rolled back because of 
unforeseen issues, which might be technical or business-related. In these scenarios, a 
defined process must be in place for rolling back a deployment into its last accepted state. 
This definition again might require approvals from both business and IT, certain acceptance 
criteria, and perhaps a break-fix environment to replicate the offending condition that caused 
the rollback request in the first place. 

Go to the IBM BPM information center for more information: 

http : //bi doc. torol ab. i bm.com: 8000 /hel p/topi c/com. i bm.wbpm.admin.doc/managi ngl i b/to 
pi c/managi ng_process_appl i cati ons_E.html 

Auditing 

Auditing process applications can take various forms. The shared infrastructure element of 
the BPM CoE is responsible for determining which audit types are required for the 
organization, and then to mandate the appropriate design, development, deployment and 
operational best practices to ensure compliance. 


52 


Creating a BPM Center of Excellence (CoE) 


Business-level auditing 

This type of auditing is also known as application-level logging, which differs from system 
logging. Application-level logging logs data from a business perspective and contains 
information such user name, process name, process instance, process step name, task ID, 
and associated relevant business data. 

Without application-level logging, finding the problems, understanding process flow, or 
auditing user interactions can be difficult. 

Compliance auditing 

This type of auditing is typically used to satisfy legal regulations regarding who did what, 
when, why, and who approved it. Often, to remain compliant, applications that fall under SOX 
or other federal regulations must be able to produce audit logs of significant events. 

Technical auditing (logging) 

The BPM platform logs data from a system perspective. BPM uses the common WebSphere 
logger to log errors, warnings, and debug messages at the platform layer. By default, all logs 
are written to the servers SystemOut. 1 og file. This log file is not commonly available to 
process application development teams, because it is located deep within the WebSphere 
deployment. 

Interjecting business log records into the system log is not appropriate: 

► System log records are probably not meaningful to the business developer. 

► System logs might contain sensitive information about the system or even other process 
applications that are running on the same platform. 

► System logs might be inaccessible to the developers. 


Populating logs: A best practice is to have each process application populate its own 
logs. This practice allows for the separation of potentially confidential information between 
teams, and allows easy access to the logs for developers and application support 
personnel. 


Error handling 

If the platform support team must be contacted each time an application error occurs, the 
team might easily be overwhelmed. Therefore, an important approach is for process 
applications to do as much self-service error handling as possible. Errors should be properly 
caught at the service and process levels; processes can and do fail, which is universally 
recognized. By using a Process Administrator participant group in process diagrams can help 
to rectify top-level failures. 

For example, system lane activities do not have a user interface, so errors usually cannot be 
caught and serviced within the services themselves. Therefore, catching exceptions at the 
BPD layer is important so that the process flow can be sent to application support personnel 
to handle and retry. 

Often, the business will resist the concept of an Application Administrator. It might be a 
foreign concept to the business or it might be a topic that was not discussed during process 
discovery. As part of a process review, the question to be asked is “What happens if this 
activity fails?” A failed activity is a business problem and requires a business solution. 

For more information about error and exception handling in IBM BPM process applications go 
to the following location: 

http://bpmwi ki .bl ueworkslive.com/di spl ay/commwi ki /Excepti on+Handl i ng 
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4.6 Organization in depth 


The organization of the shared infrastructure element of a BPM CoE requires specific skills 
that are envisioned in roles, which are then organized in a decision-making and executable 
structure against the areas of responsibility of those roles. 


4.6.1 Roles 


A useful way to think of the shared infrastructure roles that are involved in creating a BPM 
CoE is as follows: 

1 . Start with a core group. 

2. Later, expand into an extended set of roles; these roles will be specific to your organization 
and support the core group. 

Core roles 

Core roles are described in this section. 

Executive Sponsor 

This role is for the highest-level executive who has responsibility for the shared infrastructure 
(most likely in the form of direct ownership). 

Platform Support Manager 

This person is in charge of the platform support team that “owns” the BPM platform. 

► Monitors system runtime performance. 

► Provides Level 1 support for runtime environments. 

► Works with application owners and application support teams to help resolve issues. 

► Establishes common patterns and sets standards for application logging (business event 
versus system or technical logging) error handling, and process instance recovery. 

► Ensures compliance with code promotion standards. 

BPM Technical Architect 

This person makes key decisions regarding the BPM software stack. The same person is also 
a member of the Center of Strategy. 

► Plans and evolves system capacity and architecture requirements. 

► Works with the IT Architect to develop best practices for integration into the enterprise 
architecture stack. 

► Works with IT Architect to ensure all BPM touch points are secured. 

► Establishes authentication and authorization standards for the BPM platform. 

► Establishes common standards in regard to application logging, error handling, and 
recovery. 

► Establishes platform topologies that provide appropriate scalability and availability. 

► Establishes code promotion standards. 
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IT Architect 

This role is a senior IT Architect who helps navigate through corporate compliance, 
topologies, and integrations. 

► Ensures compliance with corporate IT standards and practices. 

► Helps navigate through corporate IT governance bodies. 

► Proposes appropriate integration technologies that incorporate existing corporate assets 
such as SOA, ESB, or data marts. 

► Ensures usage of enterprise services in BPM solutions. 

► Establishes overall security standards for intellectual property protection. 

► Complies with corporate disaster recovery requirements. 

Scalable roles 

Scalable roles are described in this section. 

Platform Administrator 

This role has the following responsibilities: 

► Ensures the integrity, security, and availability of the overall system. 

► Creates new process applications, provision process applications, administer user 
authentication. 

► Typically, this role is a full-time commitment from a member of the Platform Support team. 

Network Administrator 

This role has the following responsibilities: 

► Offers specialized skills in the domain of the DMZ tier (“demilitarized zone”). 

► Takes direction from the Platform Support Manager on overall requirements for the BPM 
solutions. 

Database Administrator 

This role has the following responsibilities: 

► Implements and maintains the database tier that supports the BPM solutions. 

► Takes direction from the Platform Support Manager on overall requirements for the BPM 
solutions. 

BPM Support Engineer 

This role understands the technical composition of the solution, and also the business 
problems it is intended to solve. 
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4.6.2 Required skills and experience 


Table 4-4 describes skill and experience levels for each role. 
Table 4-4 Skills and experience levels 


Role 

Required skills and experience 

| 

► Respected as a senior operational leader in the organization 

► Understands the organization’s strategic direction 

► Aware of the overall enterprise IT strategy 

► Aware of the organization's current governance committees and 

Platform Support 
Manager 

processes 

r- 

► Experience with process design and change management 

► Respected as senior technical leader in the organization 

► Experience with iterative and agile methodology or other similar 
RAD-based methods 

BPM Technical 
Architect 

► Aware of and has direct influence on the overall enterprise IT 
strategy 

► Experience championing enterprise technical change 

% 
IT Architect 

► Experience with system design, requirements gathering 

► Respected as senior technical leader in the organization 

► Aware of the overall enterprise IT strategy 
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4.6.3 Organizational structure 

This section describes the suggested organizational structures for the shared infrastructure 
element of a BPM CoE. 

Core 

Figure 4-1 shows the organizational structure for the core roles. 



Executive Sponsor 



Platform Support 
Manager 


Figure 4-1 Core roles organizational structure 
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Scalable 

Figure 4-2 shows the organizational structure for the scalable extended roles. 


P 

V 

Executive Sponsor 



BPM Technical IT Architect 

Architect 


Platform Support 
Manager 

&> % * T 

Platform Network Database BPM Support 

Administrator Administrator Administrator Engineer 


Figure 4-2 Scalable roles organizational structure 
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Related publications 


The publications listed in this section are considered particularly suitable for a more detailed 
discussion of the topics covered in this paper. 

IBM Redbooks 

The following IBM Redbooks publication provides additional information about the topic in this 
document. Note that some publications referenced in this list might be available in softcopy 
only. 
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► Sample governance process application 
http://bpmwi ki .bl ueworksl i ve.com//x/AoRgAQ 

► IBM BPM information center 

http ://bi doc. torolab. ibm.com: 8000/hel p/topi c/com. ibm.wbpm.admin.doc/managingl ib 
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